Existing proprietary systems used in the Smart Grid space are closed and typically only support a single application. As a result, users and operators must deploy multiple networks to support multiple applications (e.g., one network for Automated Meter Reading (AMR), another network for Distribution Automation, etc.). In contrast, the Internet Protocol (IP) is an open standard that is designed to support multiple applications simultaneously. As a result, one of the main benefits of utilizing an IP architecture in the Smart Grid is the ability to provide multi-service networks carrying multiple simultaneously traffic flows with different Service Level Agreements (SLAs).
Existing IP networks share a routing topology across the entire Class of Service (CoS) range. In particular, packets are marked using the IPv6 Traffic Class field or Multi-Protocol Label Switching (MPLS) “EXP” field by the source node or the entry node (e.g., border router or gateway) in the network using access control lists (ACLs) or deep packet inspection. The IP packet is then routed along the routing topology and the packet is queued at each hop in the corresponding queue. The link bandwidth is shared across the queues and the queues are serviced according to the particular scheduling algorithms configured for each CoS. In addition, other congestion avoidance techniques are used to handle random packet drops so as trigger various back-off mechanisms.
As an example, delay sensitive traffic may be assigned to a specific CoS. Packets marked with the delay-sensitive CoS are queued at each hop in a queue that is provisioned according to the targeted SLA. While the CoS mechanism is general and has been applied successfully in many Service Providers and large enterprise networks, there are some drawbacks. The CoS mechanism requires heavy engineering techniques and a deep understanding of the network behavior in terms of applications, network topology, traffic matrix to provision the network and make effective use of the CoS. Furthermore, in current networks, the required delay is not explicitly carried in the packet itself; rather a CoS is indicated (an integer) that translates into a order of priority, which can hardly be mapped to the actual delay requirement for the packet.